🔹 前言

通常工程師們在接到新任務的時候會由 PM (Product Manager) 產生 PRD。
今天，我們也要照這個流程，先來釐清「為什麼」要做這個專案，以及我們的目標。

🔹 需求背景以及痛點

痛點：

• 在企業裡，知識分散在文件、內網 Wiki、PDF、甚至 Slack channel。
• 新人入職時，需要快速找到流程、規範、系統使用方式。
• 傳統搜尋往往無法解決 → 關鍵字搜尋結果太多、缺乏上下文。

為什麼不用現成解法？

• 關鍵字搜尋 (Elasticsearch / Wiki)：只能比對字串，語意差，回傳一堆不相關文件。
• FAQ 文件：人工維護成本高，容易過時。
• 直接問同事：效率低、會打斷他人工作。

👉 因此我們想要做一個利用 語意檢索 (Semantic Search) + LLM回答的 企業知識庫 QA Chatbot，讓員工能直接用自然語言問問題。

🔹 專案目標

• 員工可以輸入問題（例如「請假流程是什麼？」）。
• 系統會從文件庫檢索相關內容，並用大語言模型產生自然的回答。
• 保持回答正確性、可解釋性（附上來源文件）。

🎯 成功標準：

• 回答的 Top-1 準確率 > 80%
• 回答時間 < 3 秒
• 支援至少 3 種資料來源（PDF、網頁、API）

🔹 預期使用者

• 一般員工：快速查詢流程、規範。

  新人，要找「VPN 安裝方式」，不需要翻十幾份文件，直接問 Chatbot。

• 客服團隊：查詢常見問答，提升回覆效率。

  客服人員，遇到客戶問「退款流程」，Chatbot 立刻給出答案和內部政策連結。

• 技術團隊：快速檢索技術文件、API 文件。

  工程師，要確認「API v2 的驗證方式」，能快速檢索到最新文件。

🔹 系統需求

功能需求 (FRD)

• 檢索能力：支援文件分片（chunking）與向量檢索，能回傳相關性排序（Top-K），並支援 Reranker。
• 知識更新：文件可持續新增、修改，檔案變更完五分鐘更新索引（Index）。
• 安全性：僅本機開發環境使用；金鑰以 .env 管理；輸出前移除/脫敏機密欄位。
• 可擴展性：能接更多資料來源（PDF、API、Slack 等）。

非功能需求 (NFR)

測試環境：MacBook Air M3 (24GB RAM)，僅供 PoC / Demo 效能參考，實際企業部署需依硬體與雲端環境調整。

• 可靠性設計：提供健康檢查端點，並以 uvicorn --reload 或 supervisor/launchd 自動重啟。
• 效能指標：
  • 吞吐量（Throughput）：QPS 3–10（Top-K ≤ 8，100–200 筆查詢 / 60 秒壓測）。
  • 延遲（Latency）：p95 ≤ 3s（API Rerank），p95 ≤ 5s（本機 Rerank）。
  • 成本（Cost）：單次 Query 預設上限 300 tokens的情況下，平均每查詢 < NT$0.2（僅外部 API 成本）。
• 觀測性：需有 Log、Metrics、Trace，可監控 Cache Hit Rate、延遲、錯誤率與 Token 成本。

驗收準則（Acceptance）

• 功能：給定三個典型問題（流程/客服/技術），能回應並附來源連結/片段。
• 正確性：人工評估 Top-1 準確率 ≥ 70%。
• 延遲：50 筆隨機查詢壓測，p95 ≤ 3s（API Rerank），p95 ≤ 5s（本機 Rerank）。
• 吞吐量：壓測 QPS ≥ 3 時系統能穩定回應。
• 成本：記錄 100 筆 300 tokens 內的查詢，平均成本 < NT$0.2/次。
• 可用性：本機模擬 crash，系統可自動重啟並恢復服務（冷啟動 < 30s）。
• 觀測：Grafana/瀏覽器能看到基本指標（延遲、命中率、成本、錯誤率）。

💡 我們會在 Day27 - 實戰案例I- 公司內部 FAQ Chatbot 完成這個專案的實作以及驗收。
完整的 Demo 程式碼我會放在 GitHub Repo，有時候文章內只展示核心片段以避免篇幅過長。

🔹 系統架構初稿

(1) 資料處理流程

上游的文件來源（例如 PDF、Slack 對話、API 回應）會先經過 Chunking 切片，把長文拆成較小段落，再轉換成 Embedding 向量。最後這些向量會被存進 向量資料庫（Vector DB，如 Weaviate / Pinecone / FAISS），成為知識庫的基礎。

(2) 查詢流程

使用者提出問題後，系統會先將 Query 轉成 Embedding，並在向量庫裡做 相似度檢索，找到最相關的段落。接著，將「使用者問題 + 檢索結果」組合成 Context + Query，送給 LLM API（例如 OpenAI）。模型生成答案後，會同時附上 來源引用，確保可解釋性。

(3) 整體架構

把前兩個流程合併，就能看到完整的雛形系統：

• 文件來源：PDF、Web、API、Slack 等。
• Pipeline：Chunking → Embedding → 存入向量資料庫。
• 查詢流程：問題轉 Embedding → 相似度檢索 → Context + Query → LLM 回答。
• Gateway：在 LLM 回答後，透過 API Gateway 做 Rate Limit、Logging 與 Cache，確保安全性與效能。
• Client：最終，使用者可以在 Web 前端或 **Chatbot（Slack / Line / Discord）**中獲得回答。

🔹 風險與挑戰

• 幻覺 (Hallucination)：LLM 可能亂回答 → 必須加「來源引用」。
• 資料新鮮度：文件常常更新 → 需要支援快速同步。
• 隱私 / 安全：不能把內部文件外流到第三方。
• 成本爆炸：如果大家都問很長的問題，API 費用會大幅上升。
• 效能瓶頸：多人同時查詢時，Embedding、檢索與 API 延遲可能成為問題。
• 回答一致性：LLM 有隨機性，必須保證企業知識庫回答的穩定性。

🔹 接下來的二十八天

如果把今天當成是 PM 的 Kickoff Meeting，那我們的 Roadmap 可以分成幾個階段：

1. 基礎建設
   從環境準備開始，挑選合適的資料庫與模型，跑起最小可行的 RAG Pipeline。

2. 功能擴充
   學會如何讓系統接更多資料來源、處理文件更新，並逐步提升檢索與回答的準確性。

3. 架構與部署
   進一步討論 API Gateway、Rate Limit、觀測性，讓這個系統能真的跑在企業內部。

4. 實戰與進階
   後面我們會做完整案例，並探索一些更前沿的改進方式。

🔹 小結

今天，我們像 PM 一樣，把專案拆解成需求、目標、架構與風險。
我們確立了為什麼需要這個 Chatbot、它要幫誰解決什麼問題，以及成功的衡量標準。
接下來的 28 天，會按照這份 roadmap 從基礎建設到實戰應用，一步步落地實作。

Day 3 我們會正式開始環境準備，打造一個能穩定開發、重現實驗的基礎環境。

📚 參考書籍 / 文章 / 延伸閱讀

• UML Distilled: A Brief Guide to the Standard Object Modeling Language 3rd Edition - by Martin Fowler
• EnterpriseEM: Fine-tuned Embeddings for Enterprise Semantic Search 連結
• Semantic Search: Why It Matters For Enterprises [2025] 連結
• PRD 怎麼寫？我教你。- 「產品先生」／ Pagerank.ing 連結